Tentative description of the HPP miniconference

Most of the time for scheduled talks at the conf. will be broken
down by PROJECT, not by individual. It is the responsibility of each
project to coordinate a meaningful sequence of talks by its members.

Day 1: Each project will present general material, dealing with:
	a) The domain of the project; e.g., enough background on the
		variables involved in medical diagnosis, and heuristics
		used, to enable the listener to understand some details
		of why MYCIN was designed the way it is.
	b) The motivation for the program; e.g., how humans perform at this
		task, what hopes there were in trying to automate it, why
		this would be interesting or useful if successful,...
	c) The initial design of the program; the organization, the parts of
		the task that were emphasized, the parts that were omitted,
		the fundamental representations and algorithms developed.
	d) Major problems that cropped up which might be of general character;
		the potential solutions considered; how they were solved or deferred
		New innovations and ideas which might be of use in other projects.

Days 2,3: Each project will present a series of brief talks and discussions,
at a more detailed level, involving the following themes:
	a) Design of large systems
	   separation of programs from data bases
	   modular representation of knowledge
	   multiple representations, multiple internal languages, redundancy

	b) Management of large systems
	   debugging large data bases: inconsistency, assigning blame,...
	   gathering large quantities of expert knowledge, and handling it.
	   gathering up experts and dealing with them
	   program interraction with the expert in dealing with the data base
		and explaining the activities of the program.
	   pragmatics for handling huge programs, with huge time demands

	c) Heuristic Search in huge, complex spaces
	   acquiring heuristics (manually) to guide search
	   if relevant: automatic acquisition; hypothesis formation, theory
		formation, rule-learning, induction,...
	   altering and adding to this heuristic knowledge
	   assessing the power of the heuristics used
	   relationship between generating and pruning heuristics

	d) A sample session with the system (fake it if not yet running)
	   show new knowledge being entered in
	   show the variety of knowledge and abilities of the system
	   show the system actually solving a problem it was designed for
	   show the system explaining itself, assigning blame, ...
	   don't show more bells and whistles than necessary
	   don't show more internal details than necessary

	e) Interaction of the project with hardware
	   potential uses for distributed computing, parallel processes, etc.
	   Imagine a factor of 10000 increase in speed and/or memory,
		How would this affect the "success" of your present system? 
		How might you have designed it differently?

Hints to the Lecturers

1) Use common,  well-established terms for  the concepts you  will be
discussing.   Don't invent new words for  concepts which already have
adequate English words available.

1b) Conversely,  if  an English  word  has  a common  meaning,  don't
pervert it  to mean something new  just during your lecture!  If your
"MATCH"  function really just  tests for equality, then  use the word
"EQUALS"!! Don't UNNECESSARILY strain your audience's minds.

2) Try to abstract concepts  from your program to a level  above what
is merely  an implementation detail. One guideline  for deciding when
you are being too specific has been suggested by Randy Davis: If your
description uses program variable names for concepts,  then it is too
specific.

3) Try to deal with issues of importance; that means don't talk about
details that won't even interest  YOU two months from now. Also,  try
to rephrase  the issues, problems,  strategies, etc. into  as general
terms as possible.

3b)  If you think  some central  themes have been  omitted from those
already given, you're probably right. Tell us all, soon!

4) When you  get the questionaires returned  to you later this  week,
use them to build up a picture of your audience. What do they already
know? What do they really want to hear about? What DON'T they want to
hear? Why are they coming to your talk?

5) Each group should coordinate its members' talks.  When each person
has some idea of what he wants to contribute, the group will meet and
sketch a provisional schedule  of talks, topics, prerequisites,  etc.
This should be  done this month!  A tentative  schedule for the whole
conference  will be  distributed well in  advance.   Each talk should
clearly indicate  what prerequisite knowledge  will be assumed.  This
might mean handing out supplementary "dictionaries" beforehand, going
to some general talk the first day, having taken an organic chemistry
course, having  worked on that  project for  two years,...   Clearly,
some of these  are ridiculous. If you makethe prerequisites explicit,
you will avoid demanding the impossible of your audience.

6) There may be "state of the project" addresses;  panel discussions,
seminars,... Think  now about  what kind of  "inter-project" sessions
would produce the best syntheses of ideas.